1. Technical Field
The present invention relates generally to an architecture for extending the Java Security Model to allow a user or an administrator to grant or deny permissions dynamically.
2. Description of the Related Art
Java, originally developed by Sun Microsystems, is a known software programming environment in which software programs, known as Java applets or applications, are developed, tested and maintained. Java programs have found extensive use on the World Wide Web, which is the Internet""s multimedia information retrieval system.
The existing Netscape security model for Java utilizes a two-stage privilege (or permission) process: granted and enabled. If not already granted or denied, a browser conforming to the Netscape security model will prompt the user to grant or deny the permission to a Java applet or application once per web browser session. Permissions can be granted or denied for the session or permanently. In addition, the Netscape security model provides support for enable, disable and revert Privilege method calls.
To have Java applets that provide interesting browser-side functionality usually requires extra-sandbox privileges or security exemptions. In the prior art, applet developers requiring security had two choices when creating applets. They could write two applets that individually exploited the functionality of the different web browsers (i.e. Netscape Navigator and Microsoft Internet Explorer) or they could create one applet that generically called the security methods available in each browser. In either case, however, the applet would be tied to the version of the Java Runtime Environment (JRE) shipped with the browser. Applet developers thus were unable to take advantage of new JREs and the functionality that they contain.
The JavaSoft Java Plug-in allows developers and users to run applets with different JREs, such as a Java 2 JRE, in their web browser. The ability to specify other JREs allows developers to call Java 2 methods within their applets. Thus, for example, applets running with the Java Plug-in can create Java 2 security objects and call their related methods. However, to take full advantage of the Java 2 security model, developers have to rewrite their applets.
It would be desirable to allow developers to take advantage of the Java 2 security model without requiring Java applets or applications using the Netscape security classes to be rewritten. Currently, however, this is not possible, in part because Java offers only a static security model where permissions must be granted before the Java program starts. Once the Java program begins, it cannot update its policy permissions.
Moreover, in the Java 2 security model, administrators or users can easily grant access to a large group of related objects. For example, to grant read access to all files under c: mydirectory, the administrator specifies the following Java permission:
java.io.FilePermission xe2x80x9cc:/mydirectory/*xe2x80x9d, xe2x80x9creadxe2x80x9d
The administrator, however, has no easy way to grant access to a large collection of related objects while denying access to one object or a small subset of them. For example, to grant read access to all the files under c: mydirectory except for c: mydirectory private.txt, the administrator would need to specify individual permissions for each of the accessible files. Clearly, this is an impractical or even impossible task in many situations.
The present invention is an architecture for extending the Java security model to allow a user or administrator to grant permissions dynamically. By itself, the Java 2 security model does not allow additions to the collections of policy permissions after they have been loaded from the Java policy file. The inventive architecture allows Java applets and applications to dynamically prompt the user to grant a permission that does not exist in the Java policy file. If the user grants the permission, the present invention grants the permission for the ProtectionDomain to which the class asking for the permission belongs.
As is well-known, all permissions in Java 2 are considered granted (or positive). If a permission exists in a Java policy file, Java 2 considers it granted to the Java class matching the specified URL or certificate. The inventive architecture also introduces the concept of a denied (or negative) permission to the Java 2 security model. Denied permissions prohibit permission for a specified URL or certificate, even if the permission was granted in a Java policy file.
According to the invention, dynamic and denied permissions may be permanently saved so that they take effect across browser sessions. Depending on the configuration of the Java Security file, users can specify if the applet or application should prompt the user to grant or to deny a permission, not prompt and grant all or deny all permissions, or not prompt and operate with the regular Java 2 model of throwing an exception if a permission has not been granted.
According to the present invention, to store the different permission states, each Java ProtectionDomain object has a set of permissions associated with it:
Grantedxe2x80x94those permissions loaded from the static Java policy files.
Session Dynamicxe2x80x94permissions that are granted for this invocation of the browser.
Permanent Dynamicxe2x80x94permissions that are granted between browser invocations.
Session Deniedxe2x80x94permissions that are denied for this invocation of the browser.
Permanent Deniedxe2x80x94permissions that are denied between browser invocations.
For example, when a Java applet calls the AccessControlContext.checkPermission method directly or indirectly, such as through the Netscape mapped PrivilegeManager.enablePermission method, the inventive architecture checks if the permission associated with specified Target has been denied. If so, the method throws an exception. If the permission has been granted already, either statically in a policy file or dynamically during runtime, the method returns successfully. If the permission has not been granted or denied, the invention prompts the user, if configured, to grant or deny the permission. For the class that made the checkpermission or Netscape mapped call, the present invention updates the permissions for the ProtectionDomain to which the class belongs.
The foregoing has outlined some of the more pertinent objects and features of the present invention. These objects should be construed to be merely illustrative of some of the more prominent features and applications of the invention. Many other beneficial results can be attained by applying the disclosed invention in a different manner or modifying the invention as will be described. Accordingly, other objects and a fuller understanding of the invention may be had by referring to the following Detailed Description of the Preferred Embodiment.